Comparing the Eeciency of Asynchronous Systems Motivation and Introduction

A timed process algebra is developed for evaluating the temporal worst-case eeciency of asynchronous concurrent systems. For the sake of simplicity, we use a classical CCS-like algebra where actions may occur arbitrarily within a continuous time interval, yielding arbitrary relative speeds of the components. Via the timed testing approach, asynchronous systems are then related w.r.t. their worst-case eeciency, yielding an ef-ciency preorder. We show that this preorder can just as well be based on much simpler discrete time and that it can be characterized with some kind of refusal traces. Finally, precongruence results are provided for all operators of the algebra, where preex, choice and recursion require special attention. Classical process algebras like CCS model asynchronous systems, where the components have arbitrary relative speeds. To consider the temporal behaviour, several timed process algebras have been proposed, where usually systems are regarded as synchronous, i.e. have components with xed speeds. The easiest of these is SCCS Mil89], since terms are essentially the same as for CCS; the natural choice to x the speeds of components is to assume that each action takes one unit of time; so SCCS-semantics diiers from CCS-semantics essentially by excluding runs where one component performs many actions while another performs just one. Our aim is to evaluate the temporal worst-case eeciency of asynchronous concurrent systems modeled with a process algebra, and { as in the case of SCCS { we want to keep things simple by using just classical CCS-like process terms. Furthermore, we will use a variant of (must-) testing DNH84], where the testing preorder can be interpreted as comparing eeciency. A usual treatment of asynchronous systems with a timed process algebra is to allow arbitrary idling before each action Mil89, MT91]; this achieves arbitrary relative speeds, but is not suitable for deening worst-case runs since each action already can take arbitrarily long. Here, we assume each action to be performed within a given time { and to keep things simple as in SCCS, we take 1 as a common upper time bound for all actions. This enforces some progress, but different from SCCS, actions may also be performed faster than necessary; hence, components have arbitrary relative speeds and we take into account all runs of an asynchronous system. E.g. Lyn96] uses upper time bounds for asynchronous systems in the area of distributed algorithms.